The following description includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication specifically or implicitly referenced is prior art.
Numerous computer programming environments exist capable of supporting many different programming languages. For example, Microsoft's Visual Studio® integrated development environment (IDE) allows developers to create software application in many different computing languages (e.g., C#, C++, F#, Python, etc.) on the Microsoft .NET® platform. The .NET platform is able to convert a high level language to a low level intermediary language, which then executes within a common run-time framework. Although such development environments are very powerful, they still have significant limitations.
One limitation of known development environments, especially object oriented systems, is that they enforce strict rules on object instantiation. Developers are required to declare classes within source code where each class definition is used to instantiate a specific type of object. Thus, an application can have hundreds or thousands of different types of objects rendering the code quite complex and difficult to maintain or refactor. For example, a “phone object” would be substantially different than a “person object” where both objects would likely require different internal complex management infrastructure for each type of object. Examples of such complexity include how and when objects are displayed, how the display screen is populated, and how changes to data objects and their contents are displayed.
Another limitation often encountered when using complex development environments is the lack of support to display visual representations of the semantics of the programming code. However, some effort has been directed to creating visual editors allowing a developer to visualize their code as a flowchart. For example, there has been some effort focused on creating a visual editor capable of displaying DRAKON format flowcharts and writing code (see URL drakon-editor.sourceforge.net/python/python.html). Another example includes the flowchart-based programming tool called RAPTOR developed at the United States Air Force Academy (see URL raptor.martincarlisle.com). RAPTOR is a coding tool that binds code with graphical flowchart objects. Such systems allow developers to display source code in a graphical setting, but fail to provide semantic and syntactical information in a unified fashion to ease development of software. Software is not generated into complete files which other programs can call.
Some development environments, such as MS Excel, provide a visual graphical interface which displays the algorithms used alongside the data. However, these development environments have only limited abilities to change the views of the data and algorithms, which can be cumbersome to accomplish and are not saved as views into the current application, but only as instances of the application. Complex algorithms must be broken into executable stages, where each stage is an algebraic or logical construct which generates intermediate values, which are then available to successive stages of computation. Therefore the combination of stages and intermediate data values become bulky and difficult to navigate. Moreover, the use of references to define variables used in computation common to these development environments are either relative, i.e. referring to a bin or series of bins in an established grid, or absolute, where they may attempt to refer to the values required even after they are moved. Adding or removing data may require resetting ranges in the algorithms, charts, or other range-specific functions.
In conventional relational databases in widespread use, the data is housed in storage and inaccessible to the user except through queries. Such queries are available as forms or reports, which are generated by special software and incorporate queries to obtain the data they require. The interaction with the database is handled by “Middleware,” as defined in several places on-line. The user can only interact with the data through middleware, and this restricts the functionality available. Changing a view or generating a form typically require software programming for the Extract, Transform, and Load (ETL) packages which constitute the common middleware that accesses relational databases. Although some database packages expose this middleware to provide a user interface, the packages still require extensive programming.
A more ideal development environment, as discussed below in the Applicant's own work, would allow developers to create applications (e.g., software, algorithms, databases, etc.) using a kernel of just a few types of objects that link together to form executable representations of the applications. Further, a more ideal environment would provide the developer access to development tools, algorithm code, algorithm data, debugging information, or other application constructs as well as the data on which the algorithms function, all within a graphical user interface, especially all at the same time during actual run-time.
A further desirable feature of database implementation is the reduction of redundancy and repetition, freeing the database of modification anomalies. See http://en.wikipedia.org/wiki/Database_normalization However, achieving normalization leads to a proliferation of tables, so that better ways of achieving the benefits of normalization are still required.
All publications referenced herein, including U.S. provisional patent application Ser. No. 62/207,305, are incorporated by reference to the same extent as if each individual publication or patent application were specifically and individually indicated to be incorporated by reference. Where a definition or use of a term in an incorporated reference is inconsistent with or contrary to the definition of that term provided herein, the definition of that term provided herein applies and the definition of that term in the reference does not apply.
As used in the description herein and throughout the claims that follow, the meaning of “a,” “an,” and “the” includes plural reference unless the context clearly dictates otherwise. Also, as used in the description herein, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise.
The recitation of ranges of values herein is merely intended to serve as a shorthand method of referring individually to each separate value falling within the range. Unless otherwise indicated herein, each individual value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g. “such as”) provided with respect to certain embodiments herein is intended merely to better illuminate the invention and does not pose a limitation on the scope of the invention otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the invention.
Groupings of alternative elements or embodiments of the invention disclosed herein are not to be construed as limitations. Each group member can be referred to and claimed individually or in any combination with other members of the group or other elements found herein. One or more members of a group can be included in, or deleted from, a group for reasons of convenience and/or patentability. When any such inclusion or deletion occurs, the specification is herein deemed to contain the group as modified thus fulfilling the written description of all Markush groups used in the appended claims.
Thus, there is still a need for improved program development environments.